ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと

ドキュメントベースの単体テスト

ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式（以下、ドキュメントベースの単体テスト）が行われてきました。

ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票（バグ票）を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。

このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修正コストなどを記録していくことで、品質の指標となるのです。

ドキュメントベースの単体テストは、ひとつのプロセスとして昔から行われてきました。しかし、良いプロセスであるかは、適用するプロジェクトの性質に依存します。そして、テスト対象、テストの目的、手段などが大きくずれてしまうと、プロセス自体が歪んだものとなってしまいます。

xUnitの登場とユニットテスト

一方、プログラマは独自に動作検証を行っていました。それは、クラスやメソッドという小さなプログラムを対象とした動作確認です。機能や画面を対象とするのではなく、もっと小さな単位でプログラムを実行し、システム出力などを使って、プログラムが期待通りに振る舞うかを検証してきました。それはプログラミングの一環であり、テストという意識はなかったかもしれません。そして、一部のプログラマは自分たちのプロジェクトで、それらの処理をフレームワーク化し、自動的に実行して検証出来るような工夫をしていました。目的はプログラマ自身が期待通りにプログラムが動くことが保証され安心するところにあります。

時は流れ、xUnitというフレームワークが登場します。クラスやメソッドを対象とした小さな動作確認を、ユニットテストとして実施することがアジャイルのプラクティスのひとつとして紹介され ^*1、普及していきます。

JUnitもそんなxUnitのひとつです。Javaで自動化されたテストを行うための便利なフレームワークとして利用できます。また、JUnitの普及によりJavaのテストではJUnitを使うことがデファクトスタンダードとなり、他のエンジニアが書いたテストコードも同じように読めるようになるだけでなく、テストの実行方法も共通化されました。

勿論、他の言語でも同じようにユニットテスト用のフレームワークが開発されています。

ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと

近年、プロジェクトの進め方は大きく変わってきました。特に自動化の進化は激しく、テストの自動化やデプロイを自動化する継続的インテグレーションの導入も当たり前です。xUnitを導入する組織は増えてきています。ドキュメントベースの単体テストの手段をxUnitにする形で…。

ドキュメントベースの単体テストをxUnitで行うことは可能です。これまでExcelなどで管理していたテストケースをxUnitのテストコードとして実装すれば良いのです。ただし、ドキュメントで書くよりも非常に時間がかかります。また、テストケースはドキュメントならば曖昧でも書けますが、テストコードはプログラムなので書いた通りにしか実行されません。画面に対するテストコードを書くとなるとさらにコストがかかります。テストコードのメンテナンスも非常にコストがかかります。もちろん、テストコードを書く事でテストは何度でも実行出来るようになり、再テストの実行コストは大きく減りますが...。

もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。

脚注